第3章 OAuth認証

認証のためのプロトコルという勘違い

前提として、認証ではなく認可（権限委譲）のプロトコルである。

リソースサーバーとしてプロフィール情報を提供する場合に認証に使う。

「OAuth + プロフィールAPI」で認証が可能になる仕組み（シーケンス図はどっかで）

リソースサーバーは/meエンドポイントを用意し、アクセストークンに紐づくユーザーの基本情報を返す。

認可リクエストを受けた認可サーバーのOAuthサービスによって認可サーバーのアカウントの認証とクライアントアプリへの権限委譲の同意が行われる。

アクセストークンを取得したクライアントアプリはプロフィールAPIにアクセスしてプロフィール情報を取得し、この情報を持ってクライアントアプリはユーザーを認証してログイン状態にする。

OAuth認証の脆弱性

プロフィールAPIに紐づく他人のアクセストークンを取得できれば、そのユーザーになりすましてクライアントアプリにログインすることができる。

認可レスポンスを認可サーバーから返された際にアクセストークンを入れ替えてリダイレクトURIにリダイレクトさせることでなりすましが可能になる。

OAuth認証の問題と言うよりインプリシットグラントの脆弱性であると言える。

しかし不正ログインできることやリソースの漏洩はアプリケーション側の問題であると言える。

FacebookのOAuth認証

Facebookだと/debug_tokenエンドポイントと言うアクセストークンの素性を確認するエンドポイントを用意し、アクセストークンの入れ替わりを検知する。